外观
🎈 想读易懂版?
本章有易懂版(大白话讲重点,10 分钟读完):[第 10 章 写代码:脚本、修改与调试(易懂版)](../../easy/第10章 写代码:脚本、修改与调试(易懂版).md)
第 10 章 写代码:脚本、修改与调试
本章目标:掌握代码类任务的三类场景与铁律——写脚本、改代码、调试的方法论,以及代码任务的安全边界。写代码,AI 赢在速度和广度;验证和放行,永远在你手里。
10.1 场景:代码是我的核心战场
代码类任务是我的核心场景之一,包括三类:
| 场景 | 说明 | 典型例子 |
|---|---|---|
| 写脚本 | 自动化、批处理、数据处理 | 批量改名、爬取数据、统计报表 |
| 改代码 | 修 bug、加功能、重构 | 修报错、加参数、拆分模块 |
| 调试 | 定位报错、分析日志、验证修复 | 排查 KeyError、分析崩溃日志 |
10.2 写代码的四条铁律
10.2.1 铁律一:先读后改
改任何代码前,先 Read 完整上下文。 就像医生开药前先看病史:
- 不读就改 = 盲人摸象,改坏的概率极高;
- 先读上下文 = 理解设计意图,最小改动到位。
10.2.2 铁律二:最小改动
能改一行不重写十行,diff 越小越安全。
| 做法 | 风险 |
|---|---|
| 整段重写 | 新代码引入新问题,diff 无法 review |
| 最小修改 | 改动一目了然,回退容易,review 快 |
10.2.3 铁律三:验证优先
写完必须跑,不能"我觉得没问题"。
写代码 → 跑测试/运行验证 → 确认结果 → 才交付"我觉得没问题"是 bug 的温床。"测试通过了"才是交付的依据。
10.2.4 铁律四:可回退
让你能看到改动内容,随时可以撤销。
- 展示 diff 让你 review;
- 保留旧版本(或依赖 git 管理);
- 不擅自覆盖不可逆资源。
10.3 案例一:写一个批处理脚本
10.3.1 指令
写一个 PowerShell 脚本,把 downloads/ 下所有 .jpg 按拍摄日期
重命名(IMG_YYYYMMDD_序号.jpg),并输出处理日志。
要求:先试运行(-WhatIf),确认无误再真正执行。10.3.2 我的做法(逐步拆解)
① Glob 查看目录:有多少文件?命名规律?是否有重名风险?
② 写脚本,加 -WhatIf 干跑模式
③ 先试运行 → 把"将要执行的动作"列成清单给你看
④ 你确认无误 → 正式执行 → 输出处理日志(改了几个、失败几个)
⑤ 抽查改名结果 → 汇报10.3.3 为什么要"试运行"
试运行 = 免费的安全网。 批量操作不可逆,先干跑一遍"将要做什么",把风险暴露在你确认之前。凡是批量、不可逆的操作,我都坚持"先干跑,后真跑"。
10.4 案例二:修一个 bug
10.4.1 指令
src/app.py 运行报 KeyError: 'user_id',帮我定位并修复。
报错堆栈:
(贴堆栈)10.4.2 我的做法(完整流程)
① Read app.py → 看现场(先读后改)
② Grep 'user_id' → 查所有相关位置(找全引用)
③ 判断根因方向:
- 字段名拼写不一致?
- 数据源缺这个字段?
- 处理顺序问题(先用了后赋值)?
④ 读关联文件(数据源/调用方)确认
⑤ Edit 最小修复
⑥ 跑测试/复现命令 → 验证修复生效
⑦ 展示 diff → 你 review10.4.3 调试中的二分定位
调试不是瞎试,而是二分定位:
复现 → 缩小范围(注释掉一半代码)→ 定位到函数 → 定位到行
→ 确认根因 → 修复 → 验证每次二分把问题空间砍一半,通常 4~6 轮就能定位。我可以帮你做大部分定位工作,但根因判断需要你提供业务背景——这正是人机协作最有价值的地方。
10.5 调试方法论:从现象到根因
10.5.1 调试四问
| 问题 | 目的 |
|---|---|
| 必然复现还是偶发? | 偶发 → 排查并发/时序/环境 |
| 改动后出现的吗? | 是 → 重点查最近改动 |
| 只影响一条数据? | 是 → 查特定数据特征 |
| 有完整报错堆栈吗? | 有 → 从堆栈最深层开始 |
10.5.2 让我帮你调 bug 时,最好给什么
① 报错信息/堆栈(完整)
② 触发步骤(怎么复现)
③ 最近改动(改了什么之后开始坏的)
④ 预期行为(应该是什么样)这四样给齐,我定位 bug 的速度能快一倍。
10.6 代码任务的边界与安全
| 场景 | 我的做法 |
|---|---|
| 执行有副作用的命令(删除/覆盖/装依赖/推远程) | 先问你 |
| 敏感信息(密钥/密码) | 明确告知:不要写进代码和记忆 |
| 生产环境操作 | 先给影响评估,再执行 |
10.6.1 脚本安全三问
写任何脚本前,先过这三问:
- 这个操作可逆吗?(删除文件 = 不可逆 → 先备份/干跑)
- 影响范围多大?(全目录 = 大 → 先小范围试)
- 有失败兜底吗?(出错了会怎样 → 写日志、留现场)
10.7 从脚本到工具:沉淀复用
写好用的脚本,别让它躺在目录里吃灰:
| 沉淀方式 | 说明 |
|---|---|
| 存 scripts/ 目录 | 统一管理,加注释和参数说明 |
| 封装为 Skill | 一句话触发,自动执行(见第 17 章) |
| 记入记忆 | "用户环境是 Windows/PowerShell" |
好脚本 = 参数化 + 有注释 + 有日志 + 有失败处理。
10.8 练习
- 给我一个真实的批处理需求,要求先试运行再执行;
- 给我一个报错信息(含堆栈),让我走一遍"定位 → 修复 → 验证";
- 把常用的调试指令存成记忆或 Skill;
- 用 10.6 的脚本安全三问,评估你手头的一个脚本。
小结:写代码,AI 赢在速度和广度;验证和放行,永远在你手里。 四铁律(先读后改/最小改动/验证优先/可回退)+ 二分定位 + 安全三问,就是代码协作的全部心法。下一章:文件与目录的整理术。